Payment reporting systems

ABSTRACT

A system is disclosed for reporting payments to one or more credit bureaus according to instructions provided by a consumer. The system may provide the consumer with one or more user interfaces from which the consumer can select one or more options to report payments made to billers. In some embodiments, the reporting options are included as part of a biller&#39;s website or a bill payment center website. The system may enable faster reporting of payments made to some billers and may report payments made to billers who would not otherwise report payments.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/252,701 filed Apr. 14, 2014, which is a continuation-in-part of U.S.patent application Ser. No. 14/164,561 filed Jan. 27, 2014, which claimsthe benefit of U.S. Provisional Application No. 61/919,618 filed Dec.20, 2013 and U.S. Provisional App. No. 61/905,112 filed Nov. 15, 2013.Each of the above identified applications is hereby incorporated byreference as if set forth herein in its entirety.

BACKGROUND

The credit score is an important indicator of a consumer's financialhealth. A consumer's credit score may impact availability and/or terms(e.g., interest rate) of such things as credit cards, loans, rentals,and real estate mortgages, as well as impacting the consumer's abilityto find employment. Therefore, consumers have a substantial interest inmonitoring and improving their credit scores.

SUMMARY

In one embodiment, a reporting system comprises hardware processors andone or more storage devices. The storage devices store softwareinstructions for execution by the hardware processors. The system isconfigured to authenticate the identity of a consumer and access paymentdata associated with the consumer indicating a biller of the consumer.The system may then present the consumer with a user interface includingthe payment data and a selectable indicator enabling the consumer toinstruct the system to report payments to one or more credit bureaus. Inresponse to the consumer selecting the indicator, the system mayinitiate a report of the payment to one or more credit bureaus.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating one embodiment of a paymentreporting system in communication with various other systems.

FIG. 2A is a sample user interface which presents a biller's billpayment screen with a reporting option, as used in an embodiment.

FIG. 2B is a sample user interface which enables a consumer to enroll ina payment reporting service, as used in an embodiment.

FIG. 2C is a sample user interface which presents a biller's billpayment screen with an indication that payments will be reported to oneor more credit bureaus immediately after payment is made and/orconfirmed, as used in an embodiment.

FIG. 2D is a sample user interface which presents a consumer withvarious ways to set up payments and reporting, as used in an embodiment.

FIG. 2E is a sample user interface which presents a consumer withpayment confirmation information and enables the consumer to initiatereporting of the payment to one or more credit bureaus, as used in anembodiment.

FIG. 3 is a sample user interface which presents the consumer with abill payment center, as used in an embodiment.

FIG. 4 is a sample user interface which enables the consumer to validatea credit agreement, as used in an embodiment.

FIG. 5 is a sample user interface which enables a consumer to setupautomatic payment reporting, as used in an embodiment.

FIG. 6 is a sample user interface which enables a consumer to setup newaccounts to report, as used in an embodiment.

FIG. 7 is a flowchart illustrating one embodiment of a process forreporting payments to one or more credit bureaus.

FIG. 8A is a block diagram illustrating one embodiment of a billerreporting payments to one or more credit bureaus through a reportingsystem.

FIG. 8B is a block diagram illustrating multiple embodiments of a billerreporting payments to one or more credit bureaus through a reportingsystem.

FIG. 8C is a block diagram illustrating multiple embodiments of aconsumer initiating reporting of payments to one or more credit bureaus.

FIG. 9 is a block diagram illustrating one embodiment of a billerproviding multiple reporting options.

DETAILED DESCRIPTION

Data reporting is the reporting of consumer credit information by abusiness, such as a biller, to one or more credit bureaus. For example,business that require payment for a product or service that has beenreceived or used by a consumer may report billing and paymentinformation to one or more credit bureaus. Businesses that report datamay be referred to as data reporters or data furnishers, while creditbureaus, such as Experian, are referred to as credit reporting agencies(CRA). Once billing and/or payment information is received by a creditbureau, a tradeline associated with the reporting business is createdand/or updated with the new data. In general, a tradeline represents aparticular financial account of a consumer (e.g., each credit cardaccount is a different tradeline), and may be represented in variousmanners in a user interface displaying credit information. Consumers mayhave few or multiple tradelines on their record. Together, alltradelines reported on a specific consumer are included in theconsumer's credit report and can be used to determine the consumer'soverall risk or creditworthiness.

The credit score is an important indicator of a consumer's financialhealth. Consequently, having a high credit score is important toconsumers for many reasons. A consumer's credit score may impactavailability and/or terms (e.g., interest rate) of such things as creditcards, loans, leases, real estate mortgages, and so on. A poor creditscore may even prevent a consumer from finding a good job. Thus, manyconsumers have a substantial interest in monitoring and finding ways toimprove their credit scores. However, a consumer's credit report isbased on the information on their credit report, and the information ona consumer's credit report doesn't change until it is updated by a datareporter. Typically, there are two types of data reporters. The firsttype is the billers themselves. Some billers report data about theirconsumer accounts directly to the credit bureaus. The second type isthird party data furnishers (also referred to as third party datareporters). These companies report to the credit bureaus on behalf ofone or more companies with consumer credit accounts. In both cases, thebillers receiving payments from consumers and/or the third party datareporters typically aggregate payment information from many consumersand only report to the credit bureaus periodically (e.g., every 30days). Thus, if a consumer makes a payment with the hope of improvinghis credit score there is often a substantial delay before anyimprovement actually occurs. For consumers seeking a quick improvementto their credit scores, this delay can be costly. In some embodiments ofthe disclosed systems, a consumer can report payment faster than relyingon traditional reporting procedures and can ensure that some payments,that may otherwise not be reported, are reported.

Although several embodiments, examples and illustrations are disclosedbelow, the inventions described herein extend beyond the specificallydisclosed embodiments, examples and illustrations and includes otheruses of the inventions and modifications and equivalents thereof.Embodiments are described with reference to the accompanying figures,wherein like numerals refer to like elements throughout. The terminologyused in the description presented herein is not intended to beinterpreted in any limited or restrictive manner simply because it isbeing used in conjunction with a detailed description of certainspecific embodiments of the invention. In addition, various embodimentscan comprise several novel features and no single feature is solelyresponsible for its desirable attributes or is essential to practicingthe inventions herein described.

System Block Diagram

FIG. 1 is a block diagram illustrating one embodiment of a paymentreporting system 100 that may be used to implement certain systems andmethods discussed herein, such as providing billing information to aconsumer, gathering a consumer's account data, enabling a consumer toreport payments to one or more credit bureaus, and/or processingpayments to one or more billers. Each of these features is discussedfurther below with reference to the various figures.

In one embodiment, the payment reporting system 100 is configured tointerface with multiple devices and/or data sources. The paymentreporting system 100 may be configured to implement certain systems andmethods described herein. The functionality provided for in thecomponents and modules of the payment reporting system 100 may becombined into fewer components and modules or further separated intoadditional components and modules.

The payment reporting system 100 may be used to implement systems andmethods described herein, such as providing billing information to aconsumer, gathering a consumer's account data, enabling a consumer toinitiate immediate payment reports to one or more credit bureaus, and/orprocessing payments to one or more billers. In the embodiment of FIG. 1,the payment reporting system 100 may include modules that may beexecuted by CPU 105 such as an account data gathering module 150, a userinterface module 110, a payment module 170, a reporting module 180, anidentity verification module 195, and a credit agreement validationmodule 190. In some embodiments, the other computing devices discussedherein, such as the computing devices 162, may include some or all ofthe same components as discussed below with reference to paymentreporting system 100. Furthermore, depending on the embodiment, certainmodules, such as the user interface module 110, account data gatheringmodule 150, payment module 170, and/or reporting module 180 may beperformed by different and/or multiple computing devices. For example,certain functionality of the reporting module 180 may be performed bythe computing device 162, while other functionality of the reportingmodule 180 may be performed by billers 164.

In some embodiments, the payment reporting system 100 includes anaccount data gathering module 150, which performs various tasks ofgathering payment data and other data relating to one or more accountsof a consumer (e.g., a consumer operating the consumer computing device162 in FIG. 1). Such data may include, for example, account detailsassociated with specific accounts, records of payments made by aconsumer, credit data retrieved from credit bureau(s) 106, and/orpayments due on the accounts. The account data may be retrieved via anetwork 160, via a dedicated communication channel, or by other means.In some embodiments, account data is communicated to the paymentreporting system 100 via a secured communication channel to ensure theprivacy and security of the data. In an embodiment, account data isgathered on demand as required by the payment reporting system. Forexample, account data may be gathered when a consumer requests to viewbilling information. In another embodiment, account data is gathered ona periodic basis independent of requests for information to the paymentreporting system. For example, account gathering module 150 may gathernew account data for specific accounts on a daily basis regardless ofrequests for information from the consumer. In another embodiment,account data is stored on the payment reporting system, in which case,retrieval of account data may not be necessary.

The payment reporting system 100 may also include a payment module 170configured to process payments from a consumer to one or more billers164. The payments may be processed through the payment reporting system100 or using a third party payment processor (e.g., Yodlee or Fiserv).When processing payments the system 100 may interact with one or morefinancial institutions to direct the transfer of money from an accountassociated with the consumer to an account associated with a biller 164.When processing payments through a third party payment processor, thesystem 100 may transmit payment information including accountinformation for the consumer and the biller to the third party paymentprocessor. The third party payment processor may then use the paymentinformation to cause the transfer of money from the consumer to thebiller.

In one embodiment, the reporting module 180 is configured to reportpayments to one or more credit bureaus. In some embodiments, the paymentreporting module 180 may report payments that have been processed bypayment module 170, and/or may report payments made through othermodules or systems. Reporting module 180 may be configured to reportpayment information faster than waiting for reporting of the paymentfrom the billers receiving payments. Reporting module 180 may also beconfigured to report payments made to a biller 164 that does nototherwise report payments. Payments may be reported directly by thereporting system 100 to the credit bureau 106 over the network 160, ormay be made through an intermediate third-party reporter 168. Paymentmodule 170 and reporting module 180 may include executable instructionsfor processing and reporting payments, respectively. The modules mayinclude portions that are executed by the payment reporting system 100,by billers 164, by bill payment center 165, and/or by the computingdevice 162. Thus, discussion herein of operations performed by thepayment module 170 and the reporting module 180 may be performedentirely by the payment reporting system 100, entirely by anothercomputing device, or some portions may be performed by the paymentreporting system 100 while other portions are performed by anothercomputing device. Furthermore, other computing systems may also performall or some of the processes discussed with reference to the paymentmodule 170 or reporting module 180.

The payment reporting system 100 may also include a credit agreementvalidation module 190 which checks the authenticity of a consumer'saccounts to verify terms of the credit agreement, e.g., to make surethat the consumer really has an account with a biller/biller for whichthe consumer is requesting payment reporting. The accounts may bevalidated with data from a credit bureau 106, a biller 164, other datasources 166, and/or information received from computing device 162. Theidentity verification module 195 verifies the consumer's identity, forexample, before reporting payment information.

In some embodiments, the payment reporting system 100 further includesuser interface module 110 which may access data from account datagathering module 150, billers 164, or other computing systems, and usethat data to construct user interfaces that enable the consumer toreport one or more payments to a credit bureau. Such visualization maybe presented to the end user and are designed to be easily manipulatedand/or understood by the user. In an embodiment, the user interfacestransmitted by user interface module 110 are interactive. Variousembodiments of the user interfaces that may be provided by userinterface module 110, are shown and described throughout thisspecification. Variations on such interfaces and other possibleinterfaces will be known to those of skill in the art. User interfacemodule 110 may be configured to construct user interfaces of varioustypes. In an embodiment, user interface module 110 constructs web pagesto be displayed in a web browser or computer/mobile application. The webpages may, in an embodiment, be specific to a type of device, such as amobile device or a desktop web browser, to maximize usability for theparticular device. In an embodiment, user interface module 110 may alsointeract with a client-side application, such as a mobile phoneapplication (an “app”) or a standalone desktop application, and providedata to the application as necessary to provide reporting functions tothe consumer.

Client computing device 162, which may comprise software and/or hardwarethat implements the user interface module 110, may be an end usercomputing device that comprises one or more processors able to executeprogrammatic instructions. Examples of such a computing device 162 are adesktop computer workstation, a smart phone such as an Apple iPhone oran Android phone, a computer laptop, a tablet PC such as an iPad,Kindle, or Android tablet, a video game console, or any other device ofa similar nature. In some embodiments, the client computing device 162may comprise a touch screen that allows a user to communicate input tothe device using their finger(s) or a stylus on a display screen. Thecomputing device 162 and/or payment reporting system 100 may comprisestorage systems such as a hard drive or memory, or comprise any othernon-transitory data storage medium. The storage systems may beconfigured to store executable instructions that may be executed by oneor more processors to perform computerized operations on the clientcomputing device 162, such as accept data input from a user (e.g., onthe touch screen), and/or provide output to a user using the display.These executable instructions may be transmitted to another device forexecution or processing by the device to implement the systems andmethods described herein.

The various computing devices illustrated in FIG. 1 may be in directcommunication with the payment reporting system 100 or may be incommunication with the payment reporting system 100 via the network 160,which may include any combination of networks, such as local area, widearea, Internet, etc., by way of a wired network, such as an ethernet LANor cable modem, or via a wireless method, such as through an 802.11access point or via a cell phone network. The network 160 allowscomputing devices to send (i.e. transmit) and receive electronictransmissions.

As described above, some embodiments may include portions that areexecuted by the payment reporting system 100, biller(s) 164, billpayment centers 165, and/or by the computing device 162, or are entirelyexecuted by the payment reporting system 100, biller(s) 164, billpayment center 165, or the computing device 162. Thus, discussion hereinof any structure (e.g., CPU, memory, etc.) of a computing device 162 oroperations performed by the computing device 162, billers 164, billpayment center 165 or modules of the payment reporting system 100 may beequally applied to the payment reporting system 100. Furthermore, othercomputing systems may also perform all or some of the processesdiscussed with reference to the modules of the payment reporting system100.

The biller(s) 164 may be reporting or non-reporting billers. In eithercase, the biller is a biller of the consumer. Reporting billers mayregularly report payments received from the consumer to one or morecredit bureaus. Reporting billers may include credit card companies,mortgage lenders, auto-loan lenders, and/or other billers that haveprovided credit to a consumer. Reporting billers may be required toreport payments by laws or regulations, or may report voluntarily.Non-reporting billers do not typically report payments received fromconsumer's to a credit bureau. For example, non-reporting billers mayinclude landlords and/or utility companies that have not traditionallyreported payments. A biller 164 may refer to the legal entity that lendsmoney or other services to a consumer, or may refer to the hardware andsoftware components implemented on a computer system that interact withthe payment reporting system 100 and/or the associated modules. In someembodiments, the payment reporting system 100 may operate as part of thecomputer systems of a biller 164.

Bill payment center 165 may be an online portal from which a consumercan make payments to one or more billers. In some embodiments, theconsumer may identify billers to the bill payment center 165 or thebillers may be identified automatically. The bill payment center mayinteract with a payment reporting system 100 and/or associated modulesor may perform some features and modules associated with the paymentreporting system 100. In some embodiments, the bill payment center 165may perform part of modules that are included in the payment reportingsystem 100 and other parts of the modules may be performed by othercomputing systems, such as those included as part of a biller 164 or thepayment reporting system 100. A consumer may access and interact throughthe computing system 162 with the bill payment center 165 through a webpage or other user interface provided by the bill payment center 165 oranother computer system.

Example Computing System Components

In general, the word module, as used herein, refers to logic embodied inhardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programming languagesuch as, for example, C, C++, C#. Software modules may be compiled andlinked into an executable program, installed in a dynamic link library,or may be written in an interpreted programming language such as, forexample, BASIC, Java, Perl, or Python. It will be appreciated thatsoftware modules may be callable from other modules or from themselvesor may be invoked in response to detected events and interrupts, orboth. The modules included in the payment reporting system 100 may bestored in the mass storage device 120 as executable software codes thatare executed by the CPU 105. Modules in the payment reporting system 100may include, by way of example, components, such as software components,object-oriented software components, class components and taskcomponents, processes, functions, attributes, procedures, subroutines,segments of program code, drivers, firmware, microcode, circuitry, data,databases, data structures, tables, arrays, and variables. Softwaremodules configured for execution on computing devices may be provided ona computer readable medium, such as a compact disc, digital video disc,flash drive, magnetic disc, or any other tangible medium, or as adigital download (and may be originally stored in a compressed orinstallable format that requires installation, decompression ordecryption prior to execution). Such software code may be stored,partially or fully, on a memory device of the executing computingdevice, such as the computing device 162, for execution by the computingdevice. Software instructions may be embedded in firmware, such as anEPROM. It will be further appreciated that hardware modules may becomprised of connected logic units, such as programmable gate arrays orprocessors. The modules described herein are preferably implemented assoftware modules, but may be represented in hardware or firmware.Generally, the modules described herein refer to logical modules thatmay be combined with other modules or devices into sub-modules despitetheir physical organization or storage. Other computing systems, suchas, computing device 162, billers 164, and bill payment center 165 maycomprise similar computing hardware, software, and functionality asdescribed in reference to payment reporting system 100.

In one embodiment, the payment reporting system 100 includes, forexample, one or more servers or personal computers that are IBM,Macintosh, or Linux/Unix compatible. In another embodiment, the paymentreporting system 100 includes one or more laptop computers, smartphones, personal digital assistants, or other computing devices. Thepayment reporting system 100 may include a memory 130, which may includea random access memory (“RAM”) for temporary storage of information, aread only memory (“ROM”) for permanent storage of information, and/or amass storage device, such as a hard drive, diskette, optical mediastorage device, or USB flash drive. The payment reporting system 100 mayalso contain a separate mass storage device 120 for permanent storage ofinformation. Typically, the modules of the payment reporting system arein communication with each other via a standards based bus system. Indifferent embodiments, the standards based bus system could bePeripheral Component Interconnect (PCI), Microchannel, SCSI, IndustrialStandard Architecture (ISA), and Extended ISA (EISA) architectures, forexample.

The payment reporting system 100 may be generally controlled andcoordinated by operating system software, such as Windows 95, 98, NT,2000, XP, Vista, 7, 8, SunOS, Solaris, Blackberry OS, or othercompatible operating systems. In Macintosh systems, the operating systemmay be any available operating system, such as MAC OS X. In otherembodiments, the Payment reporting system 100 may be controlled by aproprietary operating system. Conventional operating systems control andschedule computer processes for execution, perform memory management,provide file systems, networking, and I/O services, and provide a userinterface, such as a graphical user interface (“GUI”), among otherfunctions.

The example payment reporting system 100 shown in FIG. 1 includes one ormore commonly available input/output (I/O) interfaces and devices 111,such as a keyboard, mouse, touchpad, and printer. In one embodiment, theI/O interfaces and devices 111 include one or more display devices, suchas a monitor, that allow the visual presentation of data to a user. Moreparticularly, a display device provides for the presentation of GUIs,application software data, and multimedia presentations, for example.The payment reporting system 100 may also include one or more multimediadevices 140, such as speakers, video cards, graphics accelerators, andmicrophones, for example. In one embodiment, the I/O interfaces anddevices 111 comprise devices that are in communication with modules ofthe payment reporting system 100 via a network, such as the network 160,or any local area network, including secured local area networks, or anycombination thereof. In some embodiments, multimedia devices 140 and I/Ointerfaces and devices 111 may be part of computing devices 162, whichpayment reporting system 100 may interact with through network 160.

Some embodiments of a payment reporting system 100 may contain fewer oradditional elements and modules than are present in the embodiment inFIG. 1. In addition, modules illustrated in FIG. 1 as part of paymentreporting system 100 may be located and/or operated as part of othersystems. For example, modules of payment reporting system 100 may beoperated by billers 164, third-party reporter 168, and computing devices162. Some modules present in the embodiment of FIG. 1 may be implementedin part by multiple hardware devices associated with various entitiesinteracting with the payment reporting system 100.

Sample User Interfaces:

The payment reporting system 100 may present one or more user interfacesto the consumer through computing devices 162. In some embodiments, theuser interfaces may be generated and/or configured by a user interfacemodule 110, but one or more functions of the user interface module maybe performed by one or more other modules, or other suitable hardware orsoftware components. FIGS. 2A-6 illustrate some embodiments of userinterfaces that may be presented to a consumer for interaction withpayment reporting system 100. These user interfaces may be presented tothe consumer as part of a bill payment center, a biller's website, orother systems enabling a consumer to report payment data to a creditbureau.

In the user interfaces illustrated in FIGS. 2A-2E, the payment reportingsystem 100 provides reporting services to a consumer through a biller'swebsite. In these embodiments, the payment reporting system 100 may beincluded as part of a biller's hardware systems or separate hardwaresystems associated with the payment reporting system 100. In someembodiments, the payment reporting system 100 may also provide abiller's website and/or billings statements on behalf of the biller,branded with the biller's information. In some embodiments, the userinterface may be generated and provided by a biller, but the paymentreporting system 100 provides the software modules that enable reportingfeatures to be incorporated into the interface. In such cases, thebiller's hardware or software systems may execute software modulesprovided by the payment reporting system 100. The modules may beconfigured to provide the payment reporting system 100 with paymentinformation for reporting to the credit bureau(s) and/or details of aconsumer's enrollment in payment reporting services. Various examples ofinteractions between entities executing modules that are part of thepayment reporting system 100 are discussed in more detail with referenceto the block diagrams illustrated in FIGS. 9A-10.

In the user interface illustrated in FIG. 2A, the payment reportingsystem 100 presents the consumer with billing information, including anamount due and a due date. In some embodiments, additional or lessinformation may be provided. The user is also presented with severalinteractive buttons including a “Pay Now” button 210, and a “Report Now”button 220. Selecting the “Pay Now” button 210 may initiate payments tothe biller. Payments may be performed automatically upon selection, ormay require further input from the consumer as part of the same, or asecondary user interface. Selecting “Report Now” 220 may cause thepayment reporting system 100 to report payments made to the biller 164to one or more credit bureaus 106, either directly to the credit bureau106, or through a third party reporter 168. In some embodiments, abiller may be authorized to immediately report payments to a creditbureau. For example, if the biller is a credit provider for theconsumer, the biller may already be reporting payments to the creditbureaus. In such cases, selecting the “Report Now” 220 button mayexpedite the reporting process performed by the biller. In otherembodiments, the biller may not be authorized to report payments to thecredit bureaus. In these cases, before reporting to credit bureaus isperformed by the payment reporting system 100, the identity of theconsumer may need to be authenticated and/or evidence that the creditagreement relationship exists and/or terms of the credit relationshipmay need to be provided. Example user-interfaces and processes for thesesituations are discussed below.

In the user interface illustrated in FIG. 2B, the payment reportingsystem 100 attempts to enroll the consumer in payment reporting for thebiller. In some embodiments, a user interface to enroll in paymentreporting may be presented upon selection of the “Report Now” button 220as described in reference to FIG. 2A, or may be presented at anothertime when the consumer indicates an interest in reporting services. Theoption to enroll in payment reporting may be provided as part of thesame user interface, as part of a secondary user interface, or as partof a user interface provided by another entity (e.g., on a third party'swebsite)

In the user interface illustrated in FIG. 2B, the consumer is offeredtwo identity verification options before enrolling in payment reportingfor the biller. The consumer can sign up for, or login to the paymentreporting system 100. The first option for the consumer is to login tothe payment reporting system 100. If this is the first biller for whichthe consumer has attempted to enroll in payment reporting via thepayment reporting system 100, the consumer may not have a username andpassword. However, if the consumer has signed up with the paymentreporting system 100 for another biller, or for a bill payment system,the consumer may be able to confirm his identity by providing logininformation. Providing login credentials and clicking a “login to reportpayment” button 230 may complete the enrollment process at the biller'swebsite. Additional user interfaces such as illustrated in FIG. 2D(discussed further below) may also be provided to customize reportingduring the enrollment process. In some embodiments, information otherthan a username and password is used to confirm the identity of aconsumer after the consumer has an account with the payment reportingsystem 100. For example, the consumer may be required to provide theanswer to one or more security questions, such as out of walletquestions that are derived from information in the consumer's creditdata. The consumer's identity may also be confirmed using browsercookies or tags which track the consumer's identity on a specificcomputer.

If the consumer does not have login credentials, the consumer may needto sign up for reporting services account by first authenticating hisidentity. The user interface illustrated in FIG. 2B enables a consumerto sign up for reporting services. The payment reporting system 100 mayrequire more information than was required to enroll in onlinestatements and/or payments directly from the biller. For example, thebiller may not have required a valid social security number or date ofbirth, but both may be required to report payments to one or more creditbureaus. The biller's website may automatically perform some of theenrolling process, such as through one or more modules provided by thepayment reporting system 100. For instance, in the example of FIG. 2B,the biller's website provides known information about the consumer tothe payment reporting system 100 to fill in some required fields. Theconsumer may provide additional information, such as social securitynumber and date of birth through the provided user interface. In someembodiments, the payment reporting system may require fewer oradditional pieces of information than are illustrated in FIG. 2B. Theuser interface may also request other or additional identityverification from a consumer such as out-of-wallet data, for example.The consumer may complete the process by providing the requiredinformation to sign up for reporting and selecting a “setup account toreport payments” button 240. This may enroll the consumer in paymentreporting for the biller, such as by establishing an account for theconsumer at the payment reporting system 100. If the consumer then triesto report payments for a second biller, the consumer may be able toprovide identity confirmation with just a username and password asdiscussed with reference to the login process. During the process ofcreating an account with the payment reporting system 100, the consumermay be provided with information confirming the relationship between theconsumer and the payment reporting system 100 and letting the consumerknow personal information will be sent to third parties such as thirdparty reporters 168 and credit bureau(s) 106 as part of the reportingprocess.

The user interface in FIG. 2B may also enable the consumer to reportpayments without signing up or logging into a reporting system. Forexample, the biller may collect information from the consumer sufficientto report a payment to the credit bureau(s) without the consumercreating an additional account with a reporting service, such as via thereporting module 180 being executed by the biller.

The user interface shown in FIG. 2C illustrates another embodiment of abiller's website. The “Pay Now” button 210 now informs the consumer thatselecting “Pay Now” will report payments to the credit bureau(s)immediately. In some embodiments, this option may only be provided ifthe consumer's identity has been authenticated, either because thebiller is a reporting biller, or because the consumer has logged-in orsigned-up through a user interface with features such as to thosediscussed in reference to FIG. 2B. Immediately, as used in someembodiments, may mean when payment instructions are received, afterfunds in the consumer's payment account are verified, after confirmationof a successful payment, or another time shortly after the consumerselects to make a payment. In some embodiments of the payment reportingsystem 100, clicking on the “Pay Now” button 210 will not cause paymentsto be reported immediately, but will offer the consumer reportingoptions as shown in FIG. 2D, or will only offer reporting options afterthe payment is successfully completed as shown in FIG. 2E.

In the user interface illustrated in FIG. 2D, the payment reportingsystem 100 provides the consumer with various reporting options. In someembodiments, this interface may be provided to the consumer when theconsumer selects either the “Pay Now” button 210, or “Report Now” button220 as shown in, for example, FIG. 2A or in a user interface withsimilar features. In the example user interface of FIG. 2D, the consumeris provided with three reporting options. First the consumer is offeredthe option 250 to initiate payment of the amount currently due and thenimmediately report the payment. Selecting this option may require theconsumer to enter more information, such as payment account information.In some embodiments, payment account information necessary to makepayments may be stored in a mass storage device 120 or other memory 130such that additional information is not required. The second option 260offered to the consumer in the sample user interface is to reportseveral past payments. This may be useful in some embodiments where thebiller is not a reporting biller. Using this option, the consumer maychoose to report only those payments made on time and in the full amountdue. The consumer may also be able to choose payments based on theeffect reporting payments will have on the consumer's credit score. Insome embodiments, the system may only be able to report payments alimited time after completion before reporting is prevented byregulations. The system may offer consumer's an option to report “allavailable payments.” In some embodiments, the system may identify asoptions for the consumer only those payments which have not beenpreviously reported. For example, the system can keep records ofreported payments and not offer those to the consumer for reporting asecond time. The system may also access the consumer's credit report toidentify from the credit report which payments have already beenreported by respective billers. In some embodiments, billers may informthe system when payments are reported to the bureau so the paymentreporting system 100 will not allow the consumer to report the samepayments a second time.

In the third option 270 presented as part of the user interface of FIG.2D, the consumer can setup automatic reporting. This option may changesettings in the user's account so that all payments made to the biller(or all on time payments or other subset of payments) are reported toone or more credit bureaus. After setting up automatic reporting, thepayment user interface shown in FIG. 2A may appear as shown in FIG. 2C.In some embodiments fewer or additional reporting options may beavailable to the consumer. The consumer may be able to update reportingoptions each time a payment is made, through settings on the biller'suser interface, through settings on a user interface associated with thepayment reporting system 100, or through other user interfaces. The userinterface illustrated in FIG. 2D may be used in other systems such asthose associated with a bill payment center 165

The user interface of FIG. 2E illustrates another embodiment of offeringthe consumer with an option to report a payment. In the reportingprocesses of the user interfaces discussed above, reporting payments toa credit bureau may be contingent on a payment being successfullycompleted to the biller. In the user interface of FIG. 2E, the biller'swebsite processes the payment before offering a “Report Now” button 210.Therefore, upon selection of the “Report Now” button 210 in FIG. 2E, thepayment reporting system 100 can initiate reporting to the creditbureaus immediately without additional confirmation of a successfulpayment. In some embodiments, the consumer may have to perform otheractions such as enrolling in reporting services in a similar manner asdiscussed above before the payment reporting system 100 may report to acredit bureau.

Sample Payment Center User Interfaces

In some embodiments, the payment reporting system 100 operates as partof, or in conjunction with a bill payment center 165. FIG. 3 illustratesa user interface of a bill payment center which allows the consumer toreport payments made through the bill payment center. In the embodimentof FIG. 3, the consumer can select a “Pay Now” button 310, a “ReportNow” button 320, or “Validate” button 330 associated with respectivebillers. Selecting “Pay Now” 310 will initiate a payment to theassociated Biller. The payment may be made immediately, for example, inthe amount due (or other value based on settings decided by theconsumer), or the payment may be processed after additional user inputon the same, or a different, user interface. Selecting the “Report Now”button 320 may cause the payment reporting system 100 to report paymentsmade through the system or to initiate a payment as well as reportingthat payment. In some embodiments, in response to selection of the“Report Now” button 320 the payment reporting system 100 may provide auser interface similar to that illustrated in FIG. 2D to enable aconsumer to choose specific payments to report and payments to make. Thecredit report system 100 may indicate which billers have creditagreements already validated by the payment reporting system 100. Forexample, in FIG. 3, the consumer's cable bill has been validated and ismarked with text 340 stating “agreement validated”. In other embodimentsother indicators may be used to show which agreements have beenvalidated such as other text, an image, or the absence of a buttonenabling the consumer to validate an agreement. Billers that do not havevalidated credit agreements may provide an option for the consumer tovalidate the agreement such as “Validate” button 330. Selecting“Validate” 330 may provide the consumer with a separate user interfaceto provide the payment reporting system 100 with more information tovalidate the credit agreement between the biller and the consumer.Before a credit agreement is validated by the credit report system 100,the “Report Now” button may be greyed, outlined, or in another mannerindicate that reporting is not possible. For example, in FIG. 3 the“report now” button 325 related to the consumer's rent is greyed insteadof solid indicating reporting is not possible at this time. In someembodiments, a validate button 330 may replace a report now button 320until the credit agreement is validated. An example user interface tovalidate a credit agreement is illustrated in FIG. 4.

The additional features described with reference to FIGS. 2A-2E may alsobe implemented as necessary or desired in the context of a bill paymentcenter 165 to enable similar interactions between a payment reportingcenter 100 and a consumer. For example, the “Pay Now” button 310 and“Report Now” button 320 may initiate the same or similar interactionsand processes as described in reference to FIG. 2A, and may direct theconsumer to similar secondary user interfaces where necessary. Theconsumer may identify billers individually as described in reference toFIG. 5. A biller may also automatically be included on a bill paymentcenter user interface if the consumer enrolls in automatic payment orreporting through the payment reporting system 100 at the biller'swebsite. In some embodiments, the payment reporting system 100identifies biller's for the consumer through other data sources, such asfrom a credit report and/or demographic data about the consumer.

The user interface illustrated in FIG. 4 enables a consumer to validatethe credit agreement between the consumer and a biller. This userinterface may be displayed, for example, after the consumer selects the“Validate” button on the user interface illustrated in FIG. 3. In oneembodiment, billers that report payments directly or indirectly to oneor more credit bureaus must have a valid credit arrangement with theconsumer. Payments not based on a valid credit arrangement should not bereported to a credit bureau. Therefore, the payment reporting system 100may only report payments on behalf of the biller if there is a validatedcredit agreement. Therefore, in order to report payment data to a creditbureau, either directly or through a third-party reporter, the paymentreporting system 100 needs confirmation that a valid credit agreementexists, as well as confirmation of the terms of the credit arrangement.Some billers may already report to credit bureaus, and the paymentreporting system 100 may rely on the information provided to the creditbureaus from that biller to validate the credit relationship. Otherbillers may not report to credit bureaus and may require additionalvalidation of the credit agreement. For example, a landlord may notreport payments to any credit bureaus. The payment reporting system maytherefore require additional validation of the credit agreement. Thisrequirement is indicated in FIG. 3 by the presence of the “Validate”button 330 enabling the consumer to validate the relationship. In someembodiments, the credit relationship that needs to be validated (e.g.,the landlord/tenant relationship) may be established by submittingadditional information as is requested in FIG. 4. In the lease agreementexample of FIG. 4, the lease agreement may be submitted to the paymentreporting system 100 in order to validate the lease agreement and/or toidentify terms of the lease agreement. In some embodiments, validationof the credit relationship from one or more provided documents (e.g., alease agreement) may be done automatically by a computer systemconfigured to parse the information in the documents for relevant termsof the credit agreement. Alternatively, certain agreements may requirehuman review in order to manually validate the existence of a creditrelationship between the biller and the consumer and/or to identifyterms of the relationship that determine the payment reporting systems100 ability to report payments to one or more credit bureaus.

For some billers, even those that do not report to credit bureaus, thebiller may have an established relationship with the payment reportingsystem 100. In such embodiments, the biller and/or consumer may provideinformation about the credit relationship that the payment reportingsystem 100 can interpret and rely on to validate the credit agreement.Once a credit agreement is validated the payment reporting system 100can report payments to the biller to one or more credit bureaus asneeded. The user interface illustrated in FIG. 4 may also be provided,as required, in the context of reporting systems implemented on abiller's website (as discussed in reference to FIGS. 2A-2E).

In the user interface illustrated in FIG. 5, the consumer is presentedwith options to identify and setup new accounts to report. In the sampleuser interface of FIG. 5, the consumer is presented with two options toidentify billers. In the first option 510, the consumer can search forbillers already associated with the payment reporting system 100. Forexample, the payment reporting system 100 may store information forbillers that provide the features discussed in reference to FIGS. 2A-2E.The payment reporting system 100 may store information relevant forsetting up automatic reporting for these billers in the paymentreporting systems memory 130 or mass storage device 120. In someembodiments, the payment reporting system 100 may require additionalinformation such as specific terms of the credit relationship with theconsumer. In some embodiments, this information may be providedautomatically by the biller, and the payment reporting system mayautomatically validate the credit agreement. Biller's already in thesystem may also include billers with reporting setup by other consumers.For example, if a first consumer sets up reporting for a new biller, thepayment reporting system 100 may store the information acquired aboutthat biller during the setup process. If a second consumer identifiesthemselves as a payor to that biller, the payment reporting system canuse the stored information to setup reporting for the second consumer.Such information may include data formats used by the biller, accountnumbers of the biller, and other information necessary to processpayments to the biller, inform the biller of payments reported to one ormore credit bureaus, and/or to receive information from the billerindicating successful payments.

If a consumer searches for a biller, but is unable to identify thedesired biller, the consumer may be able to add a new biller to thesystem. For example, the second option 520 illustrated in FIG. 5 enablesthe consumer to attempt to add a new biller. Adding a new biller to thesystem may require the consumer to provide enough information touniquely identify the biller. For example, in the user interfaceillustrated in FIG. 5, the consumer is required to provide the name ofthe biller, the type of biller (e.g., utility, rent, etc.), the addressof the biller, and the consumer's account number with the biller. Inother embodiments, the payment reporting system may require additionalinformation such as the consumer's username and password with thebiller's electronic systems. After receiving the required informationfrom the consumer, the payment reporting system 100 may contact thebiller to attempt to setup the required relationship to report paymentsmade to the biller by the consumer and/or to make payments to thebiller. For example, the payment reporting system 100 may access thebiller's website by proxy using the consumer's credentials. The paymentreporting system 100 can then access the billing information of theconsumer to identify payments made, payments due, and other informationrelevant to reporting payments. The payment reporting system 100 mayconfirm payments made through a payment center with a biller in thismanner before reporting the payments to one or more credit bureaus. Inother embodiments the payment reporting system 100 sends a request tothe biller to setup a relationship so that the requesting consumer andfuture consumers can report payments made to the biller.

In the user interface illustrated in FIG. 6, the consumer is providedwith options to setup automatic reporting for one or more billers. Insome embodiments billers are split into reporting billers 620 andnon-reporting billers 610. As illustrated in FIG. 6, the consumer mayselect which accounts to report payments for through the paymentreporting system 100. In FIG. 6, the consumer selects which payments toautomatically report by checking boxes, but any other interactiveindicator may also be used. For accounts the consumer selects to reportautomatically, the payment reporting system 100 may automaticallyprovide payment data to one or more credit bureaus, either directly orthrough third-party reporters without requiring further input from theconsumer. The payment reporting system 100 may report immediately uponinitiating payment to a biller, or may wait to report payments untilreceiving confirmation of a successful payment. In embodiments where thepayment reporting system 100 reports at the time payments are initiated,the payment reporting system may check a payment account of the consumerfor sufficient funds before attempting to make or report a payment. Inaddition to selecting accounts for which to report payments, the systemmay also enable the consumer to determine when to report those payments.For example, the consumer may be presented with a user interface similarto that illustrated in FIG. 2D for each selected account or a similarinterface for selecting specific options for multiple accounts.

In the embodiment of FIG. 6, for non-reporting billers 610 the consumermay select to report payments to a credit bureau. Selecting this optionmay enable the consumer to report payments that would not otherwise bereported and therefore would not otherwise impact the consumer's creditscore. As noted above, reporting of payments in such an automatedfashion, whether from a reporting biller or non-reporting biller, by thepayment reporting system 100 may enable the consumer to report paymentsto a credit bureau at the time the payments are made. This may reducethe delay before payments are reported to a credit bureau and maytherefore improve the consumer's credit score faster than if theconsumer waited for the biller to report payments using its normalreporting schedule. In some embodiments the payment reporting system 100may not separate the accounts according to reporting or non-reportingbillers. The system may also display other language for the consumer toselect which payments to report. In some embodiments, the paymentreporting system 100 may provide other automatic reporting options for aconsumer. For example, the consumer may select to report only certainpayments to a biller, such as those that are sufficient and are on time,but not those payments with some deficiencies.

The user interfaces illustrated in FIGS. 2A-6 are sample embodiments ofuser interfaces that may be presented to a consumer as part ofinteractions with a payment reporting system. The user interfaces maycontain fewer or additional features than those illustrated. Theinteractive elements illustrated may be of other varieties than thoseshown in the figures. For example instead of a text button in FIG. 2A, aconsumer may choose to “Report Now” through check boxes, radio buttons,links or other interactive user interface elements. Some features shownin the context of one user interface may also be present in othercontexts as necessary or desired for increased functionality andusability by the consumer.

Example Flowchart:

FIG. 7 is a flowchart illustrating one embodiment of processes performedby a payment reporting system 100. These processes may be carried out aspart of a non-reporting biller's billing system, a reporting biller'sbilling system, or a bill payment center. The flowchart may begin inblock 710 or 720. Block 710 is the starting point when a consumerselects to make a payment. Block 720 is the starting point when aconsumer selects to report a payment that has already been made, eitherthrough the reporting system or through another system.

Beginning in block 710, the system receives a selection from a consumerto make a payment. The selection may be made through any of the userinterfaces discussed above, or other payment systems. The selection maybe to make a payment immediately, to make a payment at a later time, orto setup automatic recurring payments.

In block 730, the system makes a payment on behalf of the consumeraccording to the instructions indicated by the selection received inblock 710. In some embodiments, payments may be processed by the systemthrough one or more banking institutions. Payments may also be made bypassing financial information associated with the consumer to a thirdparty to process the required payments. Also in Block 730, the systemmay receive confirmation that the payment was successful. For example,when funds are transferred to the biller (e.g., from a payment accountof the consumer), the payment reporting system 100 may receiveconfirmation that the payment was on time and the amount was sufficient.

In block 740, the payment reporting system 100 determines if theconsumer selected immediate reporting. The consumer may have selectedimmediate reporting from one of the user interfaces illustrated in FIG.2A, 2D, 3, or 6, in a similar user interface, or by other means. If theconsumer has selected immediate reporting, the payment reporting system100 will continue the process of reporting the payment in block 770. Ifhe consumer did not select immediate reporting the payment reportingsystem may continue to block 750.

If the consumer did not select immediate reporting of the payment, inblock 750 the payment reporting system stores the consumer's paymentinformation in a payment database for later reporting to one or morecredit bureaus. The payment database may be located in memory 130, massstorage device 120, or stored in a database associated with anotherentity. The stored information includes information necessary to reportthe payment to a credit bureau at a later time. For example, storedinformation may include the payment date, the payment amount, whether ornot the payment was on time, successful payment confirmation, and otherinformation important if the payment may be reported at a later time.Should the consumer select to report payments at a later time (see e.g.,block 720), the payment reporting system 100 can use the storedinformation to make the report at that time.

If the system determines that the consumer selected immediate reportingof the payment at block 740, the method continues to block 770, whereinthe payment reporting system 100 determines if the consumer haspreviously reported payments to this biller. The system may determineboth if the consumer has previously reported any payments throughpayment reporting system 100, and whether those payments were to theparticular biller that is at issue now. If the consumer has previouslyreported payments to the particular biller, then the system may not needto authenticate the relationship any further. If the consumer has notpreviously reported payments to the biller associated with thisreporting before, the system needs to authenticate the credit agreement,and in some cases may need to further authenticate the consumer'sidentity as well.

In block 780, the credit reporting system 100 authenticates theconsumer's identity. The consumer's identity may be authenticated byrequiring additional information from the consumer as illustrated anddiscussed in reference to FIG. 2B above. If the consumer has previouslyreported payments, but not for the biller associated with the currentreporting, the system may not need to authenticate the consumer.Depending on the biller, the payment reporting system 100 may alsoauthenticate the credit agreement terms between the biller and theconsumer. Authentication of the credit agreement terms may be necessarybefore the system can report payments made to the biller. Authenticatingthe credit relationship may be performed as discussed with reference toFIG. 4 above.

In block 790, the consumer has indicated a payment for the system toreport, and the relationship on which the payment is based has beenauthenticated. The system may now report the payment to one or morecredit bureaus. Payments may be reported directly to the creditbureau(s) 106 by the payment reporting system 100 in some embodiments.Payments may also be reported through a third-party reporter 168. In oneembodiment, payments reported directly to credit bureau(s) must be madein the proper format and from an approved entity. Entities approved toreport to credit bureaus are generally reporting creditors or thirdparty data furnishers that are approved by one or more credit bureaus toreport payments on behalf of non-reporting creditors. When reportingdirectly to a credit bureau, a biller or third-party reporter mustgenerally report payments in a specific format, such as the Metro2credit reporting standard. Payment reporting processes are discussed inmore detail below with reference to FIGS. 9A-10.

Returning to Block 720, the processes of FIG. 7 can also be triggered bya selection from a consumer to report a payment made at an earlier time.The selection may be made at a biller's webpage, a bill payment centerwebpage, or another user interface which may be provided by anotherentity. In some embodiments the selection is made shortly afterconfirmation of successful payment is received, such as is shown in FIG.2E. Selection of payments to report may also be received for paymentsmade previously as shown in FIG. 2D. In some embodiments the consumercan select to report payments to more than one biller at a time and formultiple payments to those billers.

In block 760, if one or more particular payments to be reported are notidentified at block 720, the payment reporting system 100 may accesspayment records for the consumer. The payments may be stored in adatabase associated with the payment reporting system as described inreference to block 750. In some embodiments, the payments data is storedon a biller's website, or in a database associated with the biller, andthe payment reporting system 100 accesses the payment data from thebiller's resources. In some embodiments, determining which payments toreport involves determining which payments have already been reported.For example, if a consumer selects to report all available payments, thesystem may determine that only payments made during the last 12 monthsare eligible to be reported. In addition, the system may take steps toavoid reporting a payment that has already been reported by anotherentity. For example, a payment may be reported by a biller before theconsumer requests to report the same payment through the paymentreporting system 100. The payment reporting system may determine whichpayments have already been reported by requesting the reporting datafrom the biller, receiving data from the biller at the time of reportingand recording it, or by accessing the consumer's credit report anddetermining if the payment to be reported already appears on theconsumer's report.

After the payment reporting system 100 has accessed the payment data forthe consumer and determined which payments are to be reported, thesystem continues to block 770. Blocks 770, 780, and 790 operate in thesame manner whether the processes are initiated by receivinginstructions to make a payment or receiving instructions to reportpayments.

In some embodiments of FIG. 7 the flowchart may include block 755,particularly when the payments are made to a reporting biller. If thebiller reports payments from consumers in the normal course of business,then the payments will eventually be reported from the stored consumerpayment information. In block 755, the biller waits for the next batchreporting before reporting data to the credit bureau(s). When it is timefor the next batch reporting, the system moves onto block 790. In someembodiments, the biller may be notified if a payment is already reportedthrough another process (e.g., the processes occurring after a consumerselects to report payments as in block 720), then the system may notmove on to block 790 from block 755. For example, in some embodiments,the biller may store information indicating that the consumer selectedimmediate reporting (e.g., in block 740) when the payment was made. Thereporting system may then determine in block 755 that the payment hasalready been reported and should not be reported a second time to thecredit bureau. In such cases, the individual payments that have beenreported may be excluded from batch reporting. In other embodiments, thebiller may still report a payment as part of batch reporting afterreporting the payment at the time of the payment, but may include anindication that the reported payment has been previously reported.

The flowchart illustrated in FIG. 7 and described above are exampleprocesses which may be performed by the bill payment system 100 and/orother suitable computing systems, such as consumer computing devices. Insome embodiments, fewer or additional blocks may be present, or theprocesses may be performed in a different order than shown in thefigures. For example, in FIG. 7, some embodiments may not requireauthentication of the consumer's identity or the credit agreement,therefore, blocks 770 and 780 may not be required.

Example Block Diagrams

The block diagrams in FIGS. 8A-8C illustrate various embodiments ofcomputing system that may be in communication with the payment reportingsystem 100 in facilitating payment reporting to the credit bureau 106(or multiple credit bureaus 106 in some embodiments). The block diagramsillustrate example interactions between various modules of the paymentreporting system as they are implemented on hardware associated with oneor more entities and as used to report payments through the system. Forclarity, some of the hardware and software modules described withreference to the system block diagram of FIG. 1 may be omitted fromthese figures. However, in some embodiments the payment reporting system100 and/or other systems illustrated in FIGS. 8A-8C may include some orall of the omitted modules, or other additional modules not illustratedin the figures.

The block diagram in FIG. 8A illustrates the relationship between abiller 164 and the payment reporting system 100 in some embodiments. Thepayment reporting system 100 in FIG. 8A includes a payment module 170, acredit agreement validation module 190, and a reporting module 180. Insome embodiments, the payment reporting system 100 in FIG. 8A mayinclude additional modules, such as an identity verification module 195,for instance. The biller in the embodiment of FIG. 8A includes a paymentmodule 170 and a reporting module 180. As indicated in FIG. 8A, thebiller may be either a reporting or a non-reporting creditor. Theconsumer may communicate with the biller through a computing device 162.For example, computing device 162 may include one or more I/O interfacesand devices 111 and Multimedia devices 140 to allow the exchange ofinformation between the computing device 162 and the consumer. Thecomputing device 162 may display, over multimedia devices 140, one ormore of the user interfaces discussed with reference to FIGS. 2A-6 orother user interfaces associated with the biller 164 or the paymentreporting system 100. Inputs received on computing devices 162 may becommunicated over a network such as network 160 to a biller 164.

In FIG. 8A, the payment module 170 and the reporting module 180 includedin biller 164 communicate with payment reporting system 100 through apayment and reporting API 801. In some embodiments, other communicationmeans can be used to enable communication between the biller 164 and thepayment reporting system 100. In some embodiments, the payment module170 and reporting module 180 are provided by the payment reportingsystem 100 to the biller 164 to enable the payment reporting featuresdiscussed above. For example, the payment reporting system 100 mayprovide computer program instructions for execution by the biller 164 inresponse to a selection on a user interface associated with the billerthat causes the payment module 170 and reporting module 180 to sendpayment information to the payment reporting system 100 using thepayment and reporting API 801. In some embodiments, the biller 164generates the payment module 170 and reporting module 180 to interactwith the payment and reporting system 100.

When the consumer selects to make a payment or report a payment asdescribed with reference to the user interfaces and flowcharts abovethrough computing device 162, the biller 164 may perform some or all ofthe required actions. However, in the embodiment of FIG. 8A, the biller164 may pass the necessary information to make or report a payment tothe payment and reporting system 100. The payment and reporting system100 may then process a payment with payment module 170, validate acredit agreement with validation module 190, and/or report a paymentwith reporting module 180. Payments may be reported by the paymentreporting system through a third-party reporter 168, or directly to acredit bureau 106.

The block diagram of FIG. 8B illustrates additional embodiments of aconsumer interacting with the biller 164 to coordinate payments to thebiller 164 and report those payments to one or more credit bureaus 106.In FIG. 8B, both the biller 164 and the payment reporting system 100include a payment module 170 and a reporting module 180. In someembodiments of the system illustrated in FIG. 8B, only one of thepayment reporting system 100 and biller 164 include a payment module 170and/or reporting module 180. For example, in some embodiments thepayment module 170 in FIG. 8B may be operated exclusively by the biller.In such embodiments, the payments from the consumer to the biller may beprocessed without the payment reporting system 100.

The biller 164 in the embodiment of FIG. 8B has a reporting module 180.The reporting module 180 operated by the biller 164 may be capable ofreporting payments to the credit bureau(s) 106. However, in someembodiments, the biller 164 is a non-reporting entity that is notauthorized to report payments directly to the credit bureau 106.Therefore, in some embodiments the reporting module 180 located atbiller 164 transmits payment data to a reporting module 180 located atpayment reporting system 100. The payment data may include allinformation necessary to report payments to a credit bureau 106. Thereporting module 180 operated by the payment reporting system 100 maythen report payments to the credit bureau(s) 106 directly or throughthird-party reporter 168.

In some embodiments, the biller 164 receives payment information fromthe consumer computing device 162, but does not process the paymentsdirectly. Information can be transmitted from a payment module 170 atthe biller to a payment module 170 at the payment reporting system 100.The payment reporting system 100 can then initiate payments according tothe instructions. In some embodiments, the payment reporting system 100performs the actions necessary to process the payment according to theinstructions with the payment module 170. In some embodiments, thepayment module 170 on the payment reporting system 170 may also send thenecessary payment information to a third-party payment processor 802(such as Yodlee or Fiserv) to process the payment. Confirmation ofcompleted payments may be processed by the reporting module 180 toreport the payments to the credit bureau(s) 106. In some embodiments,the biller 164 may use the third party payment system directly (e.g.,through payment module 170) without the assistance of a separate paymentreporting system 100.

In some embodiments, the payment reporting system 100 gives anotification to the biller when a payment has been reported to thecredit bureau(s) 106. The biller may then avoid sending a duplicatereport. The payment reporting system 100 may also inform the creditbureau(s) 106 as part of the payment reporting that the biller is likelyto send duplicate payment data, but that it should only be recorded onlyonce. Although not pictured, the communications from the biller 164 tothe payment reporting system 100 may be performed over an API associatedwith the biller or payment reporting system 100 as discussed withreference to FIG. 8A.

The block diagram in FIG. 8C illustrates additional embodiments ofinteractions between various entities. The consumer computing device 162may still communicate with billers 164A or 164B in the manners describedin FIGS. 8A and 8B. For example, the consumer may make payments to abiller 164 at the biller's website through a payment module 170 includedin the biller's system. In addition, the consumer can interact directlywith the payment reporting system 100 to make payment to billers 164 andreport payment made to billers 164. For example, the payment reportingsystem 100 may provide a user interface to the consumer throughcomputing device 162, for example using the user interface module 110(not pictured), which enables the consumer to select options forinstructing the system to make payments to one or more billers 164. Thepayment module 170 located at the payment reporting system 100 may theninitiate a payment to one or more billers 164 either directly, orthrough third-party payment processor 802 (not pictured). Reportingbillers, such as biller 164B may then report the payment to the creditbureau(s) 106 directly. Payment reporting system 100 may also report thepayment to the credit bureau(s) on behalf of a biller 1648, such asimmediately after payment has been made to the biller 1648, rather thanas part of the normal reporting cycle used by the biller 164B. In someembodiments, the payment reporting system 100 enables the consumer toselect options to instruct the system to report payments to the creditbureau(s) 106 through a reporting module 180 as discussed with referenceto the user interfaces illustrated in FIGS. 2A-6.

Many processes of making and reporting payments may be performed asillustrated in FIG. 8C. For example a consumer may interact with apayment reporting system 100 or directly with a biller 164A or 1648.Depending on the biller, the subsequent necessary interactions may vary.Some non-limiting examples of reporting payments through a paymentreporting system 100 are described below.

In some embodiments, the consumer may communicate with a non-reportingbiller 164A, which does not regularly report payments to a credit bureau106. Such billers may include utility companies and landlords, forexample. Therefore, the traditional interaction would be for theconsumer to make a payment to the biller, and no payment to be reportedto the credit bureaus 106. However, the payment reporting system 100 mayenable the biller 164A to also offer the ability to report payments tothe credit bureau 106. In this example, the biller 164A includes areporting module 180 configured to communicate with the paymentreporting system 100 to provide payment data and instructions to reportthe payments to credit bureau 106. The payment reporting system 100 maythen report the payment(s) directly to the credit bureau(s) 106 orthrough a third-party reporter 168. The reporting module 180 located atbiller 164A may be provided by payment reporting system 100 to enablethe biller to offer reporting features to the consumer, and enable thebiller 164A to communicate with the payment reporting system 100 toexecute those features. In some embodiments, the reporting module 180located at biller 164A enables the biller to report payments to thecredit bureau(s) 106 without passing information through the paymentreporting system 100, such as by communicating directly with thethird-party reporter 168. The biller 164A and consumer may performadditional communication with the payment reporting system 100 toauthenticate the credit agreement.

In some embodiments, the consumer communicates with a reporting biller164B to complete payments. Biller 164B is a reporting biller that willreport payment information to the credit bureau(s) regardless ofadditional input from the consumer. For example, biller 164B may be acredit card company or mortgage lender. In some embodiments, biller 164Benables the consumer to report payments faster than the biller wouldreport through a typical batch reporting process. For example, thebiller 164B may provide the features described in reference to thesample user-interfaces above. The biller 164B may process theseadditional features by communicating with the payment reporting system100. The reporting module 180 and/or payment reporting module 170 mayprovide payment information to the payment reporting system 100 toenable the system to report payments to the credit bureau(s) immediatelyinstead of waiting for batch reporting 30 or more days later.

In some embodiments, the consumer communicates with the paymentreporting system 100 through computing device 162. At the paymentreporting system 100, the consumer may be able to make payments throughthe payment module 170, and report payments through reporting module180. For example, the payment reporting system 100 may be operating as abill payment center or in cooperation with a bill payment center. Tomake payments, the payment module 170 included in payment reportingsystem 100 may communicate with one or more billers (e.g., biller 164Aand biller 164B) to receive information on payments due, paymentprocessing information, and/or to execute payments to the billers.Payments may be processed directly by the payment reporting system 100,or through a third party payment processor as discussed in reference toFIG. 8B.

In some embodiments, the consumer may also report payments throughcommunication with the payment reporting system 100. For example, theconsumer may interact with one or more of the user-interfaces describedabove to provide instructions to the payment reporting system 100 toreport payments made. The payments may have been made at the paymentreporting system 100, or may have been made through communication withthe billers. Reporting module 180 may communicate with the billers toreceive information required to report the payments to the creditbureau(s), or the payment information may already be stored in thepayment reporting system 100 when payments are made through the system.After the necessary information is acquired, the payment reportingsystem 100 may report payments to the credit bureau(s) 106 directly orthrough third-party reporter 168 according to instructions received fromthe consumer.

The block diagram in FIG. 9 illustrates an example of a paymentreporting system 100 operated by a biller 164. For example, in FIG. 9,the biller 164 is a reporting biller. Payment module 170 in FIG. 9processes payments as directed by the consumer. As a data reporter,biller 164 has a standard reporting module 910. This reporting modulemay report payments in batches (e.g., every 30 days) as they arereceived from one or more consumers. In some embodiments, the biller 164may also have an expedited reporting module 920 that reports paymentsimmediately (or at least faster than module 910) to the credit bureau(s)106. The biller 164 may enable the consumer to direct the reporting ofpayments through one or more user interfaces or by other means. Forexample, the biller 164 may provide the consumer with one or more of theuser interfaces described above to enable the consumer to set reportinginstructions for payments made. The biller 164 may report directly tothe credit bureau(s) 106 or may report through a third-party reporter168. In some embodiments, the biller 164B as referenced in FIG. 8C isstructured as the biller in FIG. 9. In such embodiments, the standardreporting module 910 may report payments to the credit bureau(s) fromthe biller, while the expedited reporting module 920 may provide paymentinformation to a payment reporting system 100 to report paymentsimmediately.

Other Embodiments

Although the foregoing systems and methods have been described in termsof certain embodiments, other embodiments will be apparent to those ofordinary skill in the art from the disclosure herein. Additionally,other combinations, omissions, substitutions and modifications will beapparent to the skilled artisan in view of the disclosure herein. Whilesome embodiments of the inventions have been described, theseembodiments have been presented by way of example only, and are notintended to limit the scope of the inventions. Indeed, the novel methodsand systems described herein may be embodied in a variety of other formswithout departing from the spirit thereof. Further, the disclosureherein of any particular feature, aspect, method, property,characteristic, quality, attribute, element, or the like in connectionwith an embodiment can be used in all other embodiments set forthherein.

All of the processes described herein may be embodied in, and fullyautomated via, software code modules executed by one or more generalpurpose computers or processors. The code modules may be stored in anytype of computer-readable medium or other computer storage device. Someor all the methods may alternatively be embodied in specialized computerhardware. In addition, the components referred to herein may beimplemented in hardware, software, firmware or a combination thereof.

Conditional language such as, among others, “can,” “could,” “might” or“may,” unless specifically stated otherwise, are otherwise understoodwithin the context as used in general to convey that certain embodimentsinclude, while other embodiments do not include, certain features,elements and/or steps. Thus, such conditional language is not generallyintended to imply that features, elements and/or steps are in any wayrequired for one or more embodiments or that one or more embodimentsnecessarily include logic for deciding, with or without user input orprompting, whether these features, elements and/or steps are included orare to be performed in any particular embodiment.

Any process descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown, or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved as would be understood by those skilled in the art.

What is claimed is:
 1. A computing system, the computing systemcomprising: memory; and one or more processors in communication with thememory and configured by processor-executable instructions to: receivepayment data from a plurality of third-party entities indicatingpayments made by a user to the third-party entities, including a firstpayment made to a first third-party entity; generate user interface datato be displayed on a user computing device, the user interface datacomprising: an indication of the first payment made to the firstthird-party entity; and an interactive user interface element configuredto initiate reporting of the first payment to a credit bureau; and inresponse to a user selection of the interactive user interface element,transmit information regarding the first payment to one or more creditbureaus, wherein the information regarding the first payment istransmitted to the one or more credit bureaus before informationregarding the first payment is transmitted by the first third-partyentity to the one or more credit bureaus.
 2. The computing system ofclaim 1, wherein the computing system is further configured to determinewhether or not there is a valid credit agreement between the user andthe first third-party entity.
 3. The computing system of claim 1,wherein the computing system is further configured to authenticate auser's identity.
 4. The computing system of claim 1, wherein the userinterface data further comprises payment indicators associated withrespective third-party entities, wherein a first payment indicatorassociated with the first third-party entity is configured to enable theuser to instruct the computing system to initiate a payment to the firstthird-party entity.
 5. The computing system of claim 4, wherein thecomputing system is further configured to initiate the first payment tothe first third-party entity in response to receiving the indication ofselection of the first payment indicator.
 6. The computing system ofclaim 5, wherein the computing system is further configured to:determine whether the first payment to the first third-party entity issuccessfully completed; and in response to determining that the firstpayment is successfully completed, initiate said reporting of the firstpayment to the one or more credit bureaus.
 7. The computing system ofclaim 1, wherein transmitting the information regarding the firstpayment to the one or more credit bureaus comprises: determining whetherfirst payment data associated with the first third-party entityindicates the first payment has been successfully completed; andtransmitting at least a portion of the first payment data to the one ormore credit bureaus or a third party data reporter.
 8. The computingsystem of claim 1, wherein the computing system is further configuredto: receive, from the user, recurring reporting instructions to reportpayments automatically in response to receiving indications thatrespective payments to the third-party entities are successfullycompleted; receive an indication that a second payment was successfullycompleted; and automatically initiate reporting of the second payment tothe one or more credit bureaus in accordance with the recurringreporting instructions.
 9. The computing system of claim 1, wherein thecomputing system is further configured to: receive an indication ofselection of a second reporting indicator by the user; and in responseto receiving the indication of selection of the second reportingindicator, initiating reporting, to one or more credit bureaus, of asecond payment completed to a second third-party entity.
 10. Acomputer-implemented method comprising: receiving payment data from aplurality of third-party entities indicating payments made by a user tothe third-party entities, including a first payment made to athird-party entity; generating user interface data to be displayed on auser computing device, the user interface data comprising: an indicationof the first payment made to the third-party entity; and an interactiveuser interface element configured to initiate reporting of the firstpayment to a credit bureau; and in response to a user selection of theinteractive user interface element, transmitting information regardingthe first payment to one or more credit bureaus, wherein the informationregarding the first payment is transmitted to the one or more creditbureaus before information regarding the first payment is transmitted bythe third-party entity to the one or more credit bureaus.
 11. Thecomputer-implemented method of claim 10, wherein the user interface datafurther comprises a payment indicator associated with the payment data,wherein the payment indicator is configured to enable the user toinitiate payment to the third-party entity.
 12. The computer-implementedmethod of claim 11, wherein the method further comprises: determiningwhether the payment to the third-party entity is successfully completed;and in response to determining that the payment is successfullycompleted, initiating reporting of the payment to the one or more creditbureaus.
 13. The computer-implemented method of claim 10, wherein theuser interface data is provided as part of a website associated with thethird-party entity.
 14. The computer-implemented method of claim 10,wherein initiating reporting of the payment to one or more credit bureaucomprises: determining whether the payment data indicates the paymenthas been successfully completed; and transmitting at least a portion ofthe payment data to the one or more credit bureaus or a third party datareporter.
 15. The method of claim 10, wherein the method furthercomprises: receiving, from the user, recurring reporting instructions toreport payments automatically in response to receiving indications thatpayments to the third-party entity are successfully completed; receivingan indication that a second payment was successfully completed; andautomatically initiating reporting of the second payment to the one ormore credit bureaus in accordance with the recurring reportinginstructions.
 16. A non-transitory computer storage medium storingcomputer-executable instructions that, when executed by a processor,cause the processor to: receive payment data from a plurality ofthird-party entities indicating payments made by a user to thethird-party entities, including a payment made to a third-party entity;generate user interface data to be displayed on a user computing device,the user interface data comprising: an indication of the payment made tothe third-party entity; and an interactive user interface elementconfigured to initiate reporting of the payment to a credit bureau; andin response to a user selection of the interactive user interfaceelement, transmit information regarding the payment to one or morecredit bureaus, wherein the information regarding the payment istransmitted to the one or more credit bureaus before informationregarding the payment is transmitted by the third-party entity to theone or more credit bureaus.
 17. The non-transitory computer storagemedium of claim 16, wherein the computer-executable instructions furthercause the processor to: receive terms of a credit agreement between thethird-party entity and the user; and determine whether there is a validcredit agreement between the user and the third-party entity.
 18. Thenon-transitory computer storage medium of claim 16, wherein thecomputer-executable instructions further cause the processor to: receiveidentification information for the user; and authenticate a user'sidentity.
 19. The non-transitory computer storage medium of claim 16,wherein the computer-executable instructions further cause the processorto: receive an indication that the payment data has been reported to theone or more credit bureaus; and provide, to the third-party entity,confirmation that the payment data has been reported.